<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Products</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="The Bugzilla Guide - 3.6.4 
    Release"
HREF="index.html"><LINK
REL="UP"
TITLE="Administering Bugzilla"
HREF="administration.html"><LINK
REL="PREVIOUS"
TITLE="Classifications"
HREF="classifications.html"><LINK
REL="NEXT"
TITLE="Components"
HREF="components.html"></HEAD
><BODY
CLASS="section"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The Bugzilla Guide - 3.6.4 
    Release</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="classifications.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 3. Administering Bugzilla</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="components.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="section"
><H1
CLASS="section"
><A
NAME="products"
>3.4. Products</A
></H1
><P
>&#13;    <A
HREF="glossary.html#gloss-product"
><I
CLASS="glossterm"
>&#13;    Products</I
></A
> typically represent real-world
    shipping products. Products can be given 
    <A
HREF="classifications.html"
>Classifications</A
>. 
    For example, if a company makes computer games, 
    they could have a classification of "Games", and a separate
    product for each game. This company might also have a 
    <SPAN
CLASS="QUOTE"
>"Common"</SPAN
> product for units of technology used 
    in multiple games, and perhaps a few special products that
    represent items that are not actually shipping products 
    (for example, "Website", or "Administration").
    </P
><P
>&#13;    Many of Bugzilla's settings are configurable on a per-product
    basis. The number of <SPAN
CLASS="QUOTE"
>"votes"</SPAN
> available to 
    users is set per-product, as is the number of votes
    required to move a bug automatically from the UNCONFIRMED 
    status to the NEW status.
    </P
><P
>&#13;    When creating or editing products the following options are
    available: 
    </P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
>Product</DT
><DD
><P
> 
            The name of the product
          </P
></DD
><DT
>Description</DT
><DD
><P
> 
            A brief description of the product
          </P
></DD
><DT
>Default milestone</DT
><DD
><P
> 
            Select the default milestone for this product.
          </P
></DD
><DT
>Closed for bug entry</DT
><DD
><P
> 
            Select this box to prevent new bugs from being
            entered against this product.
          </P
></DD
><DT
>Maximum votes per person</DT
><DD
><P
> 
            Maximum votes a user is allowed to give for this 
            product
          </P
></DD
><DT
>Maximum votes a person can put on a single bug</DT
><DD
><P
> 
            Maximum votes a user is allowed to give for this 
            product in a single bug
          </P
></DD
><DT
>Confirmation threshold</DT
><DD
><P
> 
            Number of votes needed to automatically remove any
            bug against this product from the UNCONFIRMED state
          </P
></DD
><DT
>Version</DT
><DD
><P
> 
            Specify which version of the product bugs will be
            entered against.
          </P
></DD
><DT
>Create chart datasets for this product</DT
><DD
><P
> 
            Select to make chart datasets available for this product.
          </P
></DD
></DL
></DIV
><P
>&#13;    When editing a product there is also a link to edit Group Access Controls,
    see <A
HREF="products.html#product-group-controls"
>Section 3.4.4</A
>.
    </P
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="create-product"
>3.4.1. Creating New Products</A
></H2
><P
>&#13;    To create a new product:
    </P
><P
></P
><OL
TYPE="1"
><LI
><P
> 
        Select <SPAN
CLASS="QUOTE"
>"Administration"</SPAN
> from the footer and then
        choose <SPAN
CLASS="QUOTE"
>"Products"</SPAN
> from the main administration page.
        </P
></LI
><LI
><P
>&#13;        Select the <SPAN
CLASS="QUOTE"
>"Add"</SPAN
> link in the bottom right.
        </P
></LI
><LI
><P
>&#13;        Enter the name of the product and a description. The
        Description field may contain HTML.
        </P
></LI
><LI
><P
>&#13;        When the product is created, Bugzilla will give a message
        stating that a component must be created before any bugs can
        be entered against the new product. Follow the link to create
        a new component. See <A
HREF="components.html"
>Components</A
> for more
        information.
        </P
></LI
></OL
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="edit-products"
>3.4.2. Editing Products</A
></H2
><P
>&#13;      To edit an existing product, click the "Products" link from the 
      "Administration" page. If the 'useclassification' parameter is
      turned on, a table of existing classifications is displayed,
      including an "Unclassified" category. The table indicates how many products
      are in each classification. Click on the classification name to see its
      products. If the 'useclassification' parameter is not in use, the table 
      lists all products directly. The product table summarizes the information 
      about the product defined
      when the product was created. Click on the product name to edit these
      properties, and to access links to other product attributes such as the
      product's components, versions, milestones, and group access controls.
      </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="comps-vers-miles-products"
>3.4.3. Adding or Editing Components, Versions and Target Milestones</A
></H2
><P
>&#13;          To edit existing, or add new, Components, Versions or Target Milestones 
          to a Product, select the "Edit Components", "Edit Versions" or "Edit
          Milestones" links from the "Edit Product" page. A table of existing 
          Components, Versions or Milestones is displayed. Click on a item name 
          to edit the properties of that item. Below the table is a link to add 
          a new Component, Version or Milestone. 
        </P
><P
>&#13;          For more information on components, see <A
HREF="components.html"
>Components</A
>.
        </P
><P
>&#13;          For more information on versions, see <A
HREF="versions.html"
>Section 3.6</A
>.
        </P
><P
>&#13;          For more information on milestones, see <A
HREF="milestones.html"
>Section 3.7</A
>.
        </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="product-group-controls"
>3.4.4. Assigning Group Controls to Products</A
></H2
><P
> 
        On the <SPAN
CLASS="QUOTE"
>"Edit Product"</SPAN
> page, there is a link called 
        <SPAN
CLASS="QUOTE"
>"Edit Group Access Controls"</SPAN
>. The settings on this page 
        control the relationship of the groups to the product being edited.
        </P
><P
>&#13;        Group Access Controls are an important aspect of using groups for 
        isolating products and restricting access to bugs filed against those
        products. For more information on groups, including how to create, edit
        add users to, and alter permission of, see <A
HREF="groups.html"
>Section 3.15</A
>.
        </P
><P
>&#13;        After selecting the "Edit Group Access Controls" link from the "Edit
        Product" page, a table containing all user-defined groups for this 
        Bugzilla installation is displayed. The system groups that are created
        when Bugzilla is installed are not applicable to Group Access Controls.
        Below is description of what each of these fields means.
        </P
><P
>&#13;        Groups may be applicable (e.g bugs in this product can be associated
        with this group) , default (e.g. bugs in this product are in this group
        by default), and mandatory (e.g. bugs in this product must be associated
        with this group) for each product. Groups can also control access 
        to bugs for a given product, or be used to make bugs for a product 
        totally read-only unless the group restrictions are met. The best way to
        understand these relationships is by example. See 
        <A
HREF="products.html#group-control-examples"
>Section 3.4.4.1</A
> for examples of 
        product and group relationships.
        </P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>&#13;            Products and Groups are not limited to a one-to-one relationship. 
            Multiple groups can be associated with the same product, and groups
            can be associated with more than one product. 
          </P
></TD
></TR
></TABLE
></DIV
><P
>&#13;        If any group has <EM
>Entry</EM
> selected, then the 
        product will restrict bug entry to only those users 
        who are members of <EM
>all</EM
> the groups with 
        <EM
>Entry</EM
> selected.
        </P
><P
>&#13;        If any group has <EM
>Canedit</EM
> selected, 
        then the product will be read-only for any users 
        who are not members of <EM
>all</EM
> of the groups with
        <EM
>Canedit</EM
> selected. <EM
>Only</EM
> users who 
        are members of all the <EM
>Canedit</EM
> groups 
        will be able to edit bugs for this product. This is an additional 
        restriction that enables finer-grained control over products rather 
        than just all-or-nothing access levels.
        </P
><P
>&#13;        The following settings let you 
        choose privileges on a <EM
>per-product basis</EM
>.
        This is a convenient way to give privileges to 
        some users for some products only, without having 
        to give them global privileges which would affect 
        all products.
        </P
><P
>&#13;        Any group having <EM
>editcomponents</EM
> 
        selected  allows users who are in this group to edit all 
        aspects of this product, including components, milestones 
        and versions.
        </P
><P
>&#13;        Any group having <EM
>canconfirm</EM
> selected 
        allows users who are in this group to confirm bugs 
        in this product.
        </P
><P
>&#13;        Any group having <EM
>editbugs</EM
> selected allows 
        users who are in this group to edit all fields of 
        bugs in this product.
        </P
><P
>&#13;        The <EM
>MemberControl</EM
> and 
        <EM
>OtherControl</EM
> are used in tandem to determine which 
        bugs will be placed in this group. The only allowable combinations of
        these two parameters are listed in a table on the "Edit Group Access Controls"
        page. Consult this table for details on how these fields can be used.
        Examples of different uses are described below.
        </P
><DIV
CLASS="section"
><H3
CLASS="section"
><A
NAME="group-control-examples"
>3.4.4.1. Common Applications of Group Controls</A
></H3
><P
>&#13;        The use of groups is best explained by providing examples that illustrate
        configurations for common use cases. The examples follow a common syntax:
        <EM
>Group: Entry, MemberControl, OtherControl, CanEdit,
        EditComponents, CanConfirm, EditBugs</EM
>. Where "Group" is the name
        of the group being edited for this product. The other fields all
        correspond to the table on the "Edit Group Access Controls" page. If any
        of these options are not listed, it means they are not checked.      
      </P
><P
>&#13;            Basic Product/Group Restriction
          </P
><P
>&#13;          Suppose there is a product called "Bar". The 
          "Bar" product can only have bugs entered against it by users in the
          group "Foo". Additionally, bugs filed against product "Bar" must stay
          restricted to users to "Foo" at all times. Furthermore, only members
          of group "Foo" can edit bugs filed against product "Bar", even if other
          users could see the bug. This arrangement would achieved by the
          following:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="programlisting"
>&#13;Product Bar: 
foo: ENTRY, MANDATORY/MANDATORY, CANEDIT
        </PRE
></FONT
></TD
></TR
></TABLE
><P
>&#13;          Perhaps such strict restrictions are not needed for product "Bar". A 
          more lenient way to configure product "Bar" and group "Foo" would be:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="programlisting"
>&#13;Product Bar: 
foo: ENTRY, SHOWN/SHOWN, EDITCOMPONENTS, CANCONFIRM, EDITBUGS
        </PRE
></FONT
></TD
></TR
></TABLE
><P
>&#13;          The above indicates that for product "Bar", members of group "Foo" can
          enter bugs. Any one with permission to edit a bug against product "Bar"
          can put the bug
          in group "Foo", even if they themselves are not in "Foo". Anyone in group
          "Foo" can edit all aspects of the components of product "Bar", can confirm
          bugs against product "Bar", and can edit all fields of any bug against
          product "Bar".
        </P
><P
>&#13;            General User Access With Security Group
          </P
><P
>&#13;               To permit any user to file bugs against "Product A",
               and to permit any user to submit those bugs into a
               group called "Security":  
            </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="programlisting"
> 
Product A:
security: SHOWN/SHOWN
      </PRE
></FONT
></TD
></TR
></TABLE
><P
>&#13;            General User Access With A Security Product
          </P
><P
>&#13;            To permit any user to file bugs against product called "Security"
            while keeping those bugs from becoming visible to anyone
            outside the group "SecurityWorkers" (unless a member of the
            "SecurityWorkers" group removes that restriction):
          </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="programlisting"
> 
Product Security:
securityworkers: DEFAULT/MANDATORY
          </PRE
></FONT
></TD
></TR
></TABLE
><P
>&#13;            Product Isolation With a Common Group
          </P
><P
>&#13;            To permit users of "Product A" to access the bugs for
            "Product A", users of "Product B" to access the bugs for 
            "Product B", and support staff, who are members of the "Support 
            Group" to access both, three groups are needed:
          </P
><P
></P
><OL
TYPE="1"
><LI
><P
>Support Group: Contains members of the support staff.</P
></LI
><LI
><P
>AccessA Group: Contains users of product A and the Support group.</P
></LI
><LI
><P
>AccessB Group: Contains users of product B and the Support group.</P
></LI
></OL
><P
>&#13;            Once these three groups are defined, the product group controls
            can be set to:
          </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="programlisting"
>&#13;Product A:
AccessA: ENTRY, MANDATORY/MANDATORY
Product B:
AccessB: ENTRY, MANDATORY/MANDATORY
        </PRE
></FONT
></TD
></TR
></TABLE
><P
>&#13;         Perhaps the "Support Group" wants more control. For example, 
         the "Support Group"  could be permitted to make bugs inaccessible to 
         users of both groups "AccessA" and "AccessB". 
         Then, the "Support Group" could be permitted to publish
         bugs relevant to all users in a third product (let's call it 
         "Product Common") that is read-only
         to anyone outside the "Support Group". In this way the "Support Group" 
         could control bugs that should be seen by both groups. 
         That configuration would be:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="programlisting"
>&#13;Product A:
AccessA: ENTRY, MANDATORY/MANDATORY
Support: SHOWN/NA
Product B:
AccessB: ENTRY, MANDATORY/MANDATORY
Support: SHOWN/NA
Product Common:
Support: ENTRY, DEFAULT/MANDATORY, CANEDIT
      </PRE
></FONT
></TD
></TR
></TABLE
><P
>&#13;            Make a Product Read Only
          </P
><P
>&#13;            Sometimes a product is retired and should no longer have
            new bugs filed against it (for example, an older version of a software
            product that is no longer supported). A product can be made read-only
            by creating a group called "readonly" and adding products to the
            group as needed:
          </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="programlisting"
>&#13;Product A:
ReadOnly: ENTRY, NA/NA, CANEDIT
         </PRE
></FONT
></TD
></TR
></TABLE
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>&#13;            For more information on Groups outside of how they relate to products
            see <A
HREF="groups.html"
>Section 3.15</A
>.
          </P
></TD
></TR
></TABLE
></DIV
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="classifications.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="components.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Classifications</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="administration.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Components</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>